Detection of anomalies in a computer system

ABSTRACT

Systems and methods of detecting anomalies in a computing system are disclosed. The computing system can be a member of a blockchain network of a plurality of blockchains. Digests of blocks may be passed between blockchains of the plurality of blockchains, which enables each member of the blockchain network to verify an immutable record of data transactions, free of the mutual trust requirement of a typical blockchain environment. The passing of blockchain block digests further enables a member of the blockchain network to assist another member of the blockchain network to identify an anomaly within moments of when the anomaly first occurs.

RELATED APPLICATIONS

This application claims priority to U.S. Provisional Patent ApplicationNo. 62/693,870, titled DETECTION OF ANOMALIES IN A COMPUTER SYSTEM,filed Jul. 3, 2018, the entirety of which is incorporated herein byreference.

TECHNICAL FIELD

The present disclosure relates generally to the field of data security,and more particularly to systems and methods of detection of anomaliesin a computer system.

BRIEF DESCRIPTION OF THE DRAWINGS

The present embodiments will become more fully apparent from thefollowing description and appended claims, taken in conjunction with theaccompanying drawings. Understanding that the accompanying drawingsdepict only typical embodiments, and are, therefore, not to beconsidered limiting of the scope of the disclosure, the embodiments willbe described and explained with specificity and detail in reference tothe accompanying drawings.

FIG. 1 is a diagram of a block of a blockchain within a computing systemaccording to an embodiment of the present disclosure.

FIG. 2 is an illustration of an example blockchain network comprisingparticipating blockchains according to an embodiment of the presentdisclosure.

FIG. 3 is a partial flow diagram illustrating the generation ofparticular data for the block of FIGS. 1-2 according to an embodiment ofthe present disclosure.

FIG. 4 is a partial flowchart of a blockchain at and shortly afterstartup and having a collection of data pre-dating the blockchainstartup according to an embodiment of the present disclosure.

FIG. 5 is a diagram of a multiplex network including a blockchainnetwork, according to an embodiment of the present disclosure.

DETAILED DESCRIPTION

Transactional record keeping, a business practice as old as business,requires at least accuracy, accessibility, security and reliability.Technological advances both respond to and drive these demands. Computersystems (hardware and software) can facilitate, to a degree, accurate,accessible, secure, reliable transactional record keeping. A number ofaspects of computer-based transactional record keeping introduce bothnew advantages and weaknesses over older, traditional, pen-and-bookrecord keeping. For example, computer-based transactional record keepingmay be vulnerable to an intruder viewing (and copying) confidentialbusiness information such as trading triggers, investment holdings, realestate contracts, and more. Likewise, an intruder may manipulate data,effectively stealing or fraudulently redirecting corporate assets. Or anintruder may hijack a company's computing assets for illicit purposesnot directed toward the business itself, such as hiding illegalinformation and/or services behind a wholly legitimate Internet addressand providing access to other malfeasors such that the target computingsystem is subverted as a “dark web node.” These are but a fewgeneralized ways in which computers—including computers hostingtransactional record keeping—may be abused to the detriment of thecomputer's owner or operator, or even a real-world community at large.

Companies undertake a variety of measures to prevent such abuses, todetect them, and to correct them. These practices include effortsranging from simple to complex. A simple measure is the use of loginusernames associated with passwords having a required minimum degree ofcomplexity and stored as a hash behind firewall-protected routers onservers running the latest intrusion detection software. A more complexset of measures may involve username/password pairings oncertificate-secured hardware running antivirus software over a dedicatedconnection through specialized port addresses with anti-packet sniffingtechnology, noise detection, traffic monitoring in a variety of forms,redundant process and storage, and many more practices.

The degree to which a computer user, in particular, a corporate computeruser, expends resources to protect the information stored on a computingsystem, and the computing system itself may be related to the value ofthe information stored, the cost of maintaining and/or replacing thesystem, and the cost of losses (including liability to clients andthird-parties) that may be incurred by a failure to protect theinformation and/or system. An inherent issue with corporate users ofcomputer-based transactional record keeping where the value of the datamay require the highest measures of protection, is that the costs ofprotection includes the cost of added hardware, software, manpower, andcomputing time (e.g., cost of electricity, cooling, opportunity cost ordiversion from other computing tasks, etc.). While these additionalmeasures afford protection, they also introduce new concerns, such asmaintenance with minimal loss of operating time, unexpected outages, andeven the potential of additional weaknesses for a malfeasor to exploit.

The current model of computer-based transactional record keeping forsmall businesses involves operating a nominally closed computing systemto prevent intrusions by air-gapping the computing system from allexternal access. That is, the computer handling transactional recordkeeping is totally isolated from all network-based access. This creates,of course, some costs by requiring all transactions to be manuallyentered by a person having direct physical access to the computingsystem. This model may make intrusion highly infeasible as the intrudermust gain physical access to the computer directly; however, the modelemploys no means of detecting or remediating the effect of anunscrupulous employee or repairperson.

Few entities above the level of “small business” can effectivelyfunction with a totally closed, air-gapped computer-based transactionalrecord keeping system. A reasonable transaction rate for such businessesmakes manual entry of the transactions into an air-gapped computereconomically challenging, as the increased volume of transactionsrequires ever greater expense in isolated hardware, licensing, humaninteraction, training, maintenance, etc.

For larger entities, a totally air-gapped computer-based transactionalrecord keeping system is simply not feasible. Part of the reason forthis is that the nature of transactions changes in larger companies.This is because large companies have increasing volumes of internalcustomers—components of the business that execute transactions withother components of the business. As an example, a small company mightorder a dozen Doodads and a gross of Gizmos, while a large company mayorder a dozen boxcars of Doodads and a gross of pallets of Gizmos . . .and like quantities of Widgets, Nicknacks, Whatchamacallits, andThingamajigs. In the former scenario, there is a single point ofdelivery of exactly 156 items, and the same point of disposition. In thelatter, there may be thousands of products in a set of weekly orders,delivered to multiple points for redistribution to regional warehousesfor further redistribution to multiple retail units and involvingnumerous changes in quantity to supply each individual retail unit, plusmultiple points of accounting as products logically move from onecomputer to another. If some or all of these goods are perishableshaving varying handling requirements (frozen, refrigerated,non-refrigerated; stackable, non-stackable; odd size/shape; etc.), thenature and quantity of transactions to be recorded may grow by orders ofmagnitude or more.

As the volume of transactional record keeping grows, so does the cost ofsystems related to intrusion prevention, detection, and remediation.Relatedly, as the volume of intrusion prevention, detection, andremediation mechanisms in a system increases, so does the volume oftransactional record keeping. In other words, the increase intransactional data forces an increase in protection, detection, andremediation efforts, which efforts themselves generate more transactions(such as, for example, e.g., system logs and logs of various intrusionprevention and detection applications).

An industry standard for medium and larger companies is to include as apart of the computing system one or more data storage systems, or anetwork of such systems. Currently, such systems are designed to providenominally rapid record keeping in an environment of high-capacitystorage wherein the data is retained wholly “in house.” In other words,large computing systems owned or operated by a company store and processall transactional data within the logical confines of the company'sowned or leased computing systems, and may include rapidly scalable,third-party-operated servers (such as, for example, e.g., Amazon WebServices™ or Google Cloud Platform™).

Industry standards provide for a broad approach to protecting data,primarily directed to intrusion prevention. When successful, suchintrusion prevention typically detects the attempted intrusion andprevents the unauthorized access, and is usually accompanied by timelyautomated reporting to cognizant personnel. However, when intrusionprevention is unsuccessful, the intrusion may produce costly effects,and may remain undetected for an extended period of time, during whichsensitive company information, private information of customers andemployees, and more, may be exposed to a malfeasor.

By way of examples:

In 1999, an intruder was able to access a NASA server and steal thesoftware for controlling life support aboard the International SpaceStation, resulting in a three (3) week shutdown and costing $41,000 toremediate.

In 2002, an intruder was able to insert code on a server of a major, NewYork-based news provider to allow the intruder repeated access toperform Lexis-Nexis searches for three (3) months at an estimated costto the news vendor of $300,000.

In 2013, and again in 2015, servers of a data validation company ownedby a credit reporting agency were repeatedly compromised, resulting inthe theft of Social Security numbers and other personal data of fifteen(15) million customers.

In 2016, a national (US) grocery chain notified its employees and formeremployees that the online W2 service provider used by the company hadbeen compromised, exposing tax and salary data for an undisclosed numberof employees and former employees.

According to the K-12 Cybersecurity Resource Center(https://k12cybersecure.com), there have been 330 cybersecurityincidents targeting U.S. K-12 public schools since January 2016(retrieved May 4, 2018).

In 2017, one of the major credit reporting agencies disclosed that itsservers were compromised through a previously identified but unrectifiedexploit. The intrusion was first detected 77 days after the initialbreak-in, resulting in the theft of personally identifiable informationof at least 148 million consumers. The agency was still discoveringareas of data stolen nearly a year after the initial intrusion. Theagency further disclosed the breach has cost approximately US$243million, which does not include costs of litigation (several law suitshave been filed against the agency as a result of the breach and failureto timely mitigate the reach of the intruder(s)) and downstream costs tothe effected consumers and marketplaces.

The foregoing examples are merely representative, and not exhaustive,and does not address undiscovered or undisclosed breaches.

Once sensitive information is compromised, operational intrusionremediation efforts seek to restore the targeted system to nominalfunctionality; however, any stolen information—whatever its nature—isoften irretrievable. The longer an intrusion exposes data to a malfeasoror a group of malfeasors, the more data can be stolen, deleted oraltered. The target system may be further compromised during such anintrusion to enable future attacks, or even install hidden processeswhich may forward target data to the malfeasor(s) without a need for anew intrusion.

The present invention is directed to systems and methods of detectinganomalies in a computer system. An anomaly may accompany or besymptomatic of an attack against the computer system, or an intrusion,including an intrusion occurring in tandem with an otherwise authorizedaccess to the computer system. More particularly, the instant disclosurepresents a form of blockchain network operating in a private,semi-private, or public manner such that an anomaly on or within aparticipating computer-member may be self-detected, or, in someembodiments, detected by another participating member at or nearinception and without cross sharing of sensitive information betweenparticipating computer-members.

Anomaly refers to a state-change within a computer or computing systemoutside the expectations of the computer owner/operator. By way ofexample without limitation, an alteration to a system operating log, analteration to a computer operating system, unauthorized opening orclosing of a communication port, unauthorized access to a service of acomputer, unauthorized entry or deletion of information, unauthorizedcopying of data (within a system, or from an internal system to anexternal system), modifying firmware/software within a computer orinternal network, disabling computer protection software orsubsystem(s), etc. An intrusion into a computing system is oftenaccompanied by efforts to mask the intrusion by altering system logs.

Computer refers to an electronic device capable of executingmachine-readable instructions; is suitable for storing and/or processingdata; and comprises at least a processor, a memory, an input capability,and an output capability. A computer may be a complete computing system,or a component of a computing system. A computer is capable of one ormore of the computer functions of receiving data, processing data,storing data, transmitting data, outputting data.

Computing system refers to a computer or a collection of computers andsimilar devices communicating together to accomplish one or morefunctions of a computer.

Network refers to a system or method and related equipment ofinterconnectivity between computing systems, regardless of topology,protocol, operating system, or geophysical location.

Computer operator refers an individual, real person having dutiesintended to provide for effective operation of one or more computersystems, network systems, data systems; the duties potentially includinghardware maintenance, software management, firmware management, andsimilar functions.

Computer owner refers a person or entity owning a computer or computingsystem, or a person or entity having an ownership interest (such asrenting or purchasing access and CPU time, or leasing acomputer/computing system). A computer owner may also be a computeroperator.

Intruder refers to a person who either directly or through use of any ofa variety of software modules, applications, etc., seeks to gain accessto a computer/computing system in a manner or for a purpose other thanas intended by the owner/operator of the computer/computing system. Aperson having legitimate access to a computer may become an intruder byperforming or attempting to perform a function not intended by thecomputer owner/operator.

Intrusion prevention refers to any system or method, typicallyautomated, employed to deny or prevent unauthorized access to a targetcomputer or computing system.

Intrusion detection refers to any system or method, typically automated,employed to identify unauthorized access, attempted or successful, to acomputer/computing system.

Intrusion remediation refers to any system or method, which may beautomated or partially automated, to terminate an intrusion into acomputer/computing system; and may also refer to systems, methods,processes, etc., to negate, overcome, etc., any effect resulting from anintrusion into a computer/computing system. In the former instance,intrusion remediation seeks to identify the means by which an intrudersucceeded in accessing the system, terminating the access, andrectifying the weakness which permitted the access. In the latterinstance, intrusion remediation may involve a wide range of functions,including restoration of services, recovery of data, identification ofdamage, accountability to stakeholders, compliance with local ornational laws, etc.

Blockchain refers to a system or method wherein data are containedwithin a logical block, and the various blocks of data are logicallyorganized in a relative time-ordered sequence, and having an element ofthe data of each block comprising a token identifying and logicallyconnecting the block to the immediately preceding block.

Blockchain network refers to a collection of at least two blockchainswhich exchange with each other an amount of particular data whereby eachblockchain in the blockchain network provides a degree of proof-of-truthand proof-of-work for each other blockchain within the blockchainnetwork. A blockchain network may be implemented throughcross-merkelization.

Principal blockchain generally refers to a blockchain operated by aprinciple; however, within the context of this disclosure, a principalblockchain is an example blockchain discussed herein as if the readerwere the principle operating the example blockchain. Further, for thepurposes of this disclosure, the example principal blockchain isparticipating in a blockchain network.

Participating neighbor blockchain refers to a blockchain participatingin a blockchain network, exclusive of the principal blockchain butparticipating within the same blockchain network as the principalblockchain. Each of the blockchains, whether a principal blockchain or aparticipating neighbor blockchain, is a participating blockchain.

Block refers to a member unit of a blockchain, and further refers to acollection of data logically assembled together, and may include avariety of data of fixed types and sizes, and data of non-fixed typesand sizes. In other words, a block may contain, for example withoutlimitation, (1) a version identifier, (2) a block identifier, (3) anonce, (4) a digest (cryptographic hash), (5) a parent digest, (6) atimestamp, and (7) transactional data. Items (1) through (6) may eachhave a particular data type and size, while item 7 may comprise acollection of data of varying types and/or lengths. Each block cancontain a token (e.g., a parent hash), which identifies the immediatelypreceding block in the blockchain of which the block is a member.

SHA refers to a Secure Hashing Algorithm. A SHA is a one-waycryptographic function or set of functions taking as input a stringwhich may be of variable length and producing output of a fixed length.A purpose of a SHA is to produce an output string from which the inputstring cannot be derived. For purposes of this disclosure, references toSHA are directed toward a SHA-2 family implementation known as SHA256according to (or complying with) a standard of the United StatesNational Security Agency published in the Federal Information ProcessingStandards (FIPS) Pub. 180-4 by the National Institute of Standards andTechnology (NIST). SHA256 is capable of taking an input string ofvariable length of up to over 1.844e19 characters (over 2,000,000terabytes) and producing a 256-bit (32-byte) output string. In at leastsome SHA256 implementations, the input string can be (null) and producean output string. The output string of SHA256 (or another SHA) is knownas a digest. The term “hash” may be used interchangeably with digest.Other suitably secure cryptographic hashing algorithms may be used insome embodiments of the present disclosure.

A digest is an output from a secure hashing algorithm. With SHA256, thedigest is 256 bits, or 32 bytes, in length. The digest, also known as ahash (or a cryptographic hash), has a fixed length of 256 bits, thusSHA256 may produce up to 2²⁵⁶ distinct digests. The representation ofthe digest may vary in length depending on the computing system encodingmethod. For example, a hexadecimal computing system may represent thedigest as 32 character string.

Double(-)hash or double(-)hashing refers to “hashing a hash,” orgenerating a digest then using that digest as the input string foranother hash iteration to produce a new digest.

Merklize or merklizing refers to a process in which each of a collectionof data strings is processed through a SHA, and each resulting digest ispaired with another likewise-produced digest by concatenation and thenprocessed through a SHA again to produce a new digest, with theprocedure repeating until only a single digest remains. If at anyiteration an odd number of digests exists (greater than one (1)), one ofthe digests is duplicated and the duplicate concatenated to itsoriginal, then processed through the SHA. The single remaining digestmay be known as a merkle root for the particular collection of datastrings. Similarly, merklized refers to data having been processed bymerklization.

Cross-merklization refers to merklization wherein data, which may be inthe form of a digest, from one blockchain is merklized with data, whichmay also be in the form of a digest, of another blockchain. In ablockchain network, each participating blockchain contributes a digestrelating the particular blockchain's latest block to each otherparticipating blockchain, and each participating blockchain merklizestogether all digests received for the current block.

System time refers to a time of a timekeeping subsystem of a computingsystem. The present disclosure is agnostic toward the currentlyubiquitous practice of configuring a timekeeping subsystem of acomputing system to periodically synchronize itself to a remotetimekeeping system (such as a time server operated by the US NationalInstitute of Standards and Technology (NIST)). Generally, system time isconsidered absolute time within the particular computing system,regardless of synchronization to an external time server.

Relative time refers to an ordering of events based on the apparent timethe event occurred, was perceived by, or reported to the particularordering mechanism without adherence to a strict time reference. Forillustrative purposes, an Event A may occur within a computing systemCS-A at 20180601:0101:10.150 UTC, an Event B may occur within acomputing CS-B 400 milliseconds after Event A relative to UTC, and anEvent C may occur within a computing system CS-C 1,300 milliseconds (1.3seconds) after Event A, and 900 milliseconds after Event B relative toUTC. CS-A and CS-B may report the occurrence of Events A and B to CS-C,including the event system time. Because of network topology, the reportof Event B may arrive at CS-C 700 milliseconds after Event B occurred,and 200 milliseconds before Event C occurs. Because of remoteness andnetwork latency, the report of Event A may arrive at CS-C 2,900milliseconds (2.9 seconds) after Event A occurred, and 1,600milliseconds (1.6 seconds) after Event C occurred. To CS-C, the relativetime (order) of these events based on when Event C occurred within CS-Cand the reports of Events A and B arrived to CS-C is B C A, even thoughthe absolute order according to UTC is A B C.

Endianness refers to the order of significant bits in a value within acomputing system, including an input, an output, or any transitionalvalue. Big endianness refers to the ordering of bits in diminishingsignificance. Little endianness refers to the ordering of bits inincreasing significance. For example, and using base-10 for ease ofreference, a big-endian “1000” represents one thousand, which may berepresented in little endian by “0001.”

A collision refers either to identical digests (or digest collision)being produced from a SHA, or an incidence of two or more blockssimultaneously (or block collision). A digest collision, howeverunlikely, is theoretically possible from differing input strings. Adigest collision may result from multiple computing systems producingidentical digests simultaneously to each other, or nearly so, whileparticipating in, for example, a blockchain network. A block collisionmay occur when two (or more) computing systems participating in ablockchain network produce and/or deliver and/or receive blocks eitherat the same time, or having identical timestamps. Blockchain systemscomprise methods to mitigate each of these collision types in a mannerthat prevents the blockchain(s) from failing or stalling. For example, acomputing system receiving a block from another blockchain bearing anidentical timestamp to the receiving computing system's latest nativeblock may simply ignore the incoming block's timestamp and treat theincoming block as arriving immediately after the latest native block.Similarly, a blockchain participating computing system receiving a blockfrom another blockchain simultaneous to the production of a native blockmay be configured to treat the incoming block as arriving after the newnative block regardless of the incoming block's timestamp. A blockchainparticipating computing system receiving a block from each of two (ormore) participating computing systems may be configured to order themultiple incoming blocks based on one of each block's timestamp, length(also called height) of each sending blockchain, blockchain IDserialization, etc.

Collision resistance refers to an unlikelihood of different inputstrings producing a digest collision. (Because resolving a blockcollision is simply a matter of choosing how to order blocks, blockcollision resistance is not a significant concern.) Because SHA256 mayproduce up to 2²⁵⁶ distinct digests, collision resistance may be deemedquite high. In some computing applications, SHA256 collision resistancemay be theoretically decreased by artificially imposing one or morelimitations on acceptable result digests. In other words, a particularapplication may enforce a rule of x consecutive bits having a value of0, effectively reducing the number of distinct digests which theparticular application may accept as output from SHA256. Because SHA isa one-way cryptographic function, such an output-limiting rule cannotserve as an input parameter for SHA256, but only as a post-processimplementation necessitating iteratively producing digests with varyinginput strings until a rule-compliant digest is produced. In at leastsome blockchain implementations, varying the input string may beaccomplished by pre- or appending a nonce to the input string, andincrementing the nonce with each iteration of SHA until a rule-compliantdigest is produced.

Collision resolution refers to (a) system(s) or method(s) of deprecatingall identical digests but one such that each deprecated digest may beabandoned. When a digest is abandoned, the block of which the abandoneddigest is an element may also be abandoned.

Nonce refers to a 32-bit integer. A nonce may be a member of a series ofnonces. Generally, in a collection of nonces, each successive nonce isan increment of the previous nonce. An initial nonce (a nonce for afirst iteration of a block generation cycle) may be selected, forexample without limitation, by an algorithm generating a 32-bit integer,or by a protocol-stipulated initial value. A next nonce (a subsequentiteration for the same block generation cycle) may be by an algorithmagain generating a 32-bit integer, or by a protocol-stipulatedincrementing of the previously used nonce. In one embodiment, a noncemay be generated anew for each iteration without regard for the value ofthe preceding nonce.

Proof-of-work refers to generating a digest that is compliant with anoutput limitation rule imposing a requirement of x consecutive bitshaving a value of 0. Because a SHA does not take an output-controllingparameter, a digest can be compared to the rule after generation. Adigest complying with the rule is produced by iteratively generatingdigests until a compliant digest results. The compliant digest may serveas demonstrative evidence (“proof”) that an amount of computerprocessing (“work”) was expended to produce the digest. An outputlimitation rule may similarly require x consecutive bits having a valueof 1, or a defined substring of a particular length with a particularorder of 0s and 1s. A higher (longer) proof-of-work requirement mayresult in a lower collision resistance.

Target difficulty refers to an element which specifies a particularlimitation to form a proof-of-work-compliant digest. For example withoutlimitation, a target difficulty may indicate a digest must have ten (10)consecutive 0-bits in order to qualify as a proof-of-work digest.

Transaction refers to (a) an exchange of goods/service forgoods/services, goods/services for payment, exchange of debts, exchangeof promises, exchange of obligations, etc.; and (b) a computer functionwhereby a transaction of type (a) is recorded or otherwise processed;and (c) a computer function whereby a transaction of type (b) isrecorded. By way of example, a type (a) transaction may be a sale of aWidget for cash; a related type (b) transaction may by decrementing thenumber of Widgets in stock as a result of the sale; and a related type(c) transaction may be a computer log entry recording information (forexample, user identity, login time, access to inventory software,subtraction of the sold Widget, etc.) about the access which performedthe stock decrement. Transactions of type (c) may also include recordsof installation, modification, or deletion of firmware or software,including image size, digital signature, license, certificate, etc.

Transactional record keeping refers to any manner of making a record oftransactions and can be internal to a manner of protection of therecord. A record may contain data, known as record data. The termstransactional record, record, and record data may be usedinterchangeably herein.

Unauthorized access refers to any access or attempt to access acomputing system in a manner or for a purpose not intended by the ownerand/or operator of the target computing system, and includes access byan authorized user for an unauthorized purpose.

It will be readily understood that the components of the embodiments asgenerally described and illustrated in the figures herein could bearranged and designed in a wide variety of different configurations.Thus, the following more detailed description of various embodiments, asrepresented in the figures, is not intended to limit the scope of thedisclosure, as claimed, but is merely representative of variousembodiments. While the various aspects of the embodiments are presentedin drawings, the drawings are not necessarily drawn to scale unlessspecifically indicated.

The terms “a” and “an” can be described as one, but not limited to one.For example, although the disclosure may recite a tab having “a line ofstitches,” the disclosure also contemplates that the tab can have two ormore lines of stitches.

Unless otherwise stated, all ranges include both endpoints and allnumbers between the endpoints.

Reference throughout this specification to “an embodiment” or “theembodiment” means that a particular feature, structure, orcharacteristic described in connection with that embodiment is includedin at least one embodiment. Thus, the quoted phrases, or variationsthereof, as recited throughout this specification are not necessarilyall referring to the same embodiment.

FIG. 1 is a diagram of a block 10 of a blockchain within a computingsystem 1 according to an embodiment of the present disclosure. Thecomputing system 1 may be a principal computing system operated by acomputer operator to at least implement the blockchain 10. The block 10may be produced or otherwise implemented on the computing system 1 by ablockchain implementation according to an embodiment of the presentdisclosure. The block 10 comprises a block identifier (or block ID) 12,a blockchain version (or blockchain version identifier) 14, a blockchainidentifier (or blockchain ID) 16, a timestamp 18, a proof-of-work region(or POWR) 20 (which may be considered a set within the meaning ofmathematical set theory), a block digest 30, a target difficulty 40, ablocknonce 50, and a collection 60 of contributing digests. The block 10may include one or more records digest(s) 70, 72, 74, and may beconsidered a set within the meaning of mathematical set theory. Theblock 10 may include one or more block headers 80, 82. The block 10 mayinclude a collection 90 of records and may include record data.

The computing system 1 may include one or more computing devices, eachcomprising one or more processors, one or more computer readable media,one or more electronic memory, one or more input/output devices, and/orone or more communication interfaces.

The order of the elements 12-90 shown in FIG. 1 is for the convenienceof the reader, and not a requirement of a particular embodiment of thedisclosure. An embodiment of the present disclosure may have moreelements than described herein, or fewer, and may be structured orotherwise arranged in any of a variety of ways in storage on one or morecomputer readable media.

FIG. 2 is an illustration of an example blockchain network 100comprising three participating blockchains, namely a principalblockchain 200, a first participating neighbor blockchain 300, and asecond participating neighbor blockchain 400, according to an embodimentof the present disclosure. The principal blockchain 200 may beimplemented on a principal computing system, such as the computingsystem 1 of FIG. 1. The principal blockchain 200 comprises a principalseries of blocks (or series of blocks), of which a block 210 accordingto one embodiment is identified. The block 10 of FIG. 1 is also shown inthe context of the blockchain network 100 and the principal blockchain200. Although FIG. 2 depicts three participating blockchains 200, 300,400 in the blockchain network 100, additional participating neighborblockchains may be present in an embodiment of a blockchain networkaccording to the present disclosure.

The initial block 210 of the principal blockchain 200 comprises at leasta unique block ID 212, a blockchain version 214, a blockchain ID 216, atimestamp 218, and a data region 230. The unique block ID 212 isanalogous to (and value-wise distinct from) the unique block ID 12 ofthe block 10. The blockchain version 214 is analogous to the blockchainversion 14 of the block 10. The blockchain ID 216 is analogous to theblockchain identifier 16 of the block 10. The timestamp 218 is analogousto (and value-wise distinct from) the timestamp 18 of the block 10. Thedata region 230 may include elements analogous to other elements of theblock 10 of FIG. 1 and may include elements not identified in FIG. 1. Aninitial block 310 of the first participating neighbor blockchain 300 isidentified, having elements 312, 314, 316, 318, 330 generally analogousto the block 210 of the principal blockchain 200. An initial block 410of the second participating neighbor blockchain 400 is identified,having elements 412, 414, 416, 418, 430 generally analogous to theinitial block 210 of the principal blockchain 200.

Each of the initial blocks 210, 310, 410 is represented at the lowestaspect of the respective blockchains 200, 300, 400, although this is forease of reference only. The initial blocks 210, 310, 410 may besucceeded each by a series of blocks within the respective blockchain200, 300, 400 of each initial block 210, 310, 410. By way of example,the initial block 210 of the principal blockchain 200 is shown to have asucceeding block 10 _(P), to which the block 10 is a subsequentlysucceeding block, and the block 10 is shown with a further succeedingblock 10 _(N). Each of the succeeding blocks 10 _(P), 10, 10 _(N), etc.,of the principal blockchain 200 has a timestamp analogous to thetimestamp 218 of the block 210. The timestamp (analogous to thetimestamp 218) of each succeeding block 10 _(P), 10, 10 _(N) is shown asrecording successively later times. Within the principal blockchain 200,the timestamps recorded in each succeeding block form an absolute timereference within the principal blockchain 200.

The participating neighbor blockchains 300, 400, similarly arerepresented having successively later succeeding blocks 310 _(P), 410_(P), and otherwise generally and functionally resemble the principalblockchain 200. Like the succeeding block timestamps of the principalblockchain 200, succeeding block timestamps of each participatingneighbor blockchain 300, 400 form an absolute time reference within therespective blockchain 300, 400.

The principal blockchain 200 may be resident within the computing system1 of FIG. 1 from which the blockchain 200 derives the time for eachsucceeding block timestamp. Each participating neighbor blockchain 300,400 may similarly reside within a respective, distinct computing system,which may be analogous to the computing system 1 of the principalblockchain 200. Each participating neighbor blockchain 300, 400 mayderive the time for each succeeding block timestamp with the respectiveblockchain 300, 400 from the system time of the computing system(analogous to the computing system 1 of the blockchain 200) wherein therespective participating neighbor blockchain 300, 400 resides. As may bewell understood by one of ordinary skill in the art, each of theplurality of computing systems may have differing system time settings.

The principal blockchain 200 may be agnostic with regard to the relativetime of production of a block within a participating neighbor blockchain300, 400. As each such block of a participating neighbor blockchain 300,400 is communicated to the principal blockchain 200, the principalblockchain 200 may be aware of a relative time that the blockchain 200becomes aware of the existence of the block from the participatingneighbor blockchain 300, 400. More broadly, as each of the blockchains200, 300, 400 creates a block, for example the blocks 210, 310, 410respectively, and communicates the same among the other blockchains 200,300, 400 within the blockchain network 100, each of the blockchains 200,300, 400 may note 112 the creating of each succeeding block and mayorder 114 the blocks in a time-advancing 110 series. In other words,each blockchain 200, 300, 400 may be aware of the time order 114 of thecreation (or communication of creation) of each block of each blockchain200, 300, 400 in the blockchain network 100, whereby the series ofblocks within the blockchains 200, 300, 400 may be chronologicallylinked.

Reference is now made to FIGS. 1 and 2. In the present example, theblock 10 of FIG. 1 is a member of the principal blockchain 200 in FIG.2. The block ID 12 may be unique to the block 10. In other words, eachblock in a blockchain may have a unique block ID 12. The blockchainversion 14 may identify the particular implementation of blockchainprotocol used by the principal blockchain 200 in producing the block 10.The blockchain ID 16 may identify the particular blockchain 200 of whichthe block 10 is a member. The blockchain ID 16 is shown as a 4-bytehexadecimal representation as a matter of convenience only and is not arequirement of this disclosure. (In an embodiment, a binary tree may beimplemented.) The blockchain ID 16 may be formed in a variety ofdifferent ways, provided the blockchain ID 16 can be unique to eachblockchain. The timestamp 18 may report the system time at which theblock 10 was produced. The timestamp 18 may take the form of, forexample without limitation, a Unix epoch timestamp, or any other formcompliant with an embodiment of a blockchain protocol according to thisdisclosure.

The block digests collection 60 comprises most recent digests 66, 64, 62from each blockchain 200, 300, 400 participating in the blockchainnetwork 100. In the example of FIG. 1, the block digests collection 60comprises the digest 62 of a most recent block of the participatingneighbor blockchain 300, the digest 64 of a most recent block of theparticipating neighbor blockchain 400, and the digest 66 of a mostrecent block in the principal blockchain 200 immediately preceding theblock 10.

The block digest 30 is created by merklizing the digest 62 and digest64. In other words, the digests 62, 64 are concatenated so as to form asingle 64-byte string, which is then processed through SHA. The outputof merklizing the digests 62, 64 through SHA is a 32-byte string whollycomprising the block digest 30. Because each digest 62, 64, 66 iscontributed by a different blockchain 200, 300, 400, the merklization ofthese digests 62, 64, 66 is, in particular, cross-merklization. In ablockchain network having more than three participating blockchains, theblock digests collection 60 may comprise a block digest from eachparticipating blockchain, and each such digest may be cross-merklized,and a merkle root of block digests produced to generate the block digest30. The block 10 includes the digest 66 that was produced in the samemanner as part of the most recent block 10 _(P) prior to and within theprincipal blockchain 200. The digest 66 may connect the block 10 to themost recent previously created block 10 _(P) within the principalblockchain 200.

Similarly, a protocol of the blockchain 200 of the block 10 may pass theblock digest 30 of the immediately succeeding block 10 _(N) in theprincipal blockchain 200. In this manner, the block 10 _(N) succeedingthe block 10 is connected to the block 10, and the block 10 is connectedto the most recent block 10 _(P) preceding the block 10. Thisinterconnection of blocks is inherent throughout the principalblockchain 200 and serves to connect each block to its immediatepredecessor and successor.

Similarly, the digest 62 may have been passed from the participatingneighbor blockchain 300 to the principal blockchain 200, and the digest64 may have been passed from the participating neighbor blockchain 400to the principal blockchain 200. This connects the block 10 to animmediately preceding block 310 _(P), 410 _(P) within each participatingneighbor blockchain 300, 400 similar to connecting the block 10 to theimmediately preceding block 10 _(P) within the principal blockchain 200.

The protocol of blockchain 200 of block 10 may likewise direct a passingof the block digest 30 to each participating neighbor blockchain 300,400 such that an immediately succeeding block 310 _(N), 410 _(N) of eachparticipating neighbor blockchain 300, 400 may be connected to the block10 of the principal blockchain 200. In this manner, each participatingblockchain 200, 300, 400 is connected to each other participatingblockchain 200, 300, 400. More particularly, the principal blockchain200 is directly connected to each participating neighbor blockchain 300,400 by having directly received from each participating neighborblockchain 300, 400 previous block digests 62, 64 of the blocks 310_(P), 410 _(P); and by sending the block digest 30 to each of theparticipating neighbor blockchains 300, 400. The participating neighborblockchains 300, 400 are indirectly connected to each other as a resultof each participating neighbor blockchain 300, 400 sending block digests(analogous to digests 62, 64) to the principal blockchain 200, andreceiving from the principal blockchain 200 block digests (analogous todigests 64, 62) of the other participating neighbor blockchain 400, 300.The blockchain protocol of each participating blockchain 200, 300, 400may cross-merklize the digests (analogous to 62, 64, 66) into eachparticipating blockchain's next succeeding block. Thiscross-merklization process may proliferate throughout the blockchainnetwork 100, thereby interconnecting the participating blockchains 200,300, 400 in a cryptographically and independently verifiable manner. Thecross-merklization process decouples immutability from consensus. Morespecifically, by sharing (i.e., sending a block digest 30) to otherparticipating neighbor blockchains 300, 400 in the blockchain network100, immutability of the data (which is an objective of and enabled by ablockchain) is decoupled from the consensus (i.e., a mechanism forreaching agreement among participants to add a block) of theparticipating blockchains 200, 300, 400.

FIG. 3 is a partial flow diagram illustrating the generation of data forthe block 10 (upper right corner of FIG. 3), according to an embodimentof the present disclosure. The block 10 may be analogous to block 10 ofFIGS. 1-2 and, as previously described, may be immediately preceded inthe principal blockchain 200 by the block 10 _(P). Beginning at thebottom of the flow diagram, a digest 66 of the block 10 _(P) may bepassed 701 directly to the block 10. The digest 66 may serve asreference to the block 10 _(P) as the block immediately preceding theblock 10 being generated. The latest preceding block 310 _(P) of theparticipating neighbor blockchain 300 may be communicated (see 324 inFIG. 2) to the principal blockchain 200. The digest 62 of the block 310_(P) may be extracted and passed 702 directly to the block 10.Similarly, a latest preceding block 410P of the participating neighborblockchain 400 may be communicated (see 422 in FIG. 2) to the principalblockchain 200, and the digest 64 extracted and passed 703 directly tothe block 10.

The target difficulty 40 may also be extracted 704 from the precedingblock 10 _(P). In one embodiment, the target difficulty 40 may also beextracted from the block 310 _(P), 410 _(P) of the participatingneighbor blockchain 300, 400 for comparison to the target difficulty 40of the preceding block 10 _(P) as an additional validity check prior toincluding data from the participating neighbor blockchain 300, 400 intothe block 10.

The digest 62 from the block 310 _(P) and the digest 64 from the block410 _(P) may be concatenated together 710, 711 to form an input string29. The order of appearance in the concatenation may be set as arequirement of a particular implementation of the blockchain protocol ofthe blockchain network 100. The input string 29 may then be processedthrough a SHA 600 to generate 713 a block digest 30 for the block 10.The block digest 30 may be passed 766 (through R4) to the block 10. At alater stage, when the principal blockchain 200 is generating thesucceeding block 10 _(N), the block digest 30 may be passed as anelement of the block 10 to the block 10 _(N), and may serve as areference from the block 10 _(N) back to the block 10, which includesthe digest 66 as a reference to the preceding block 10 _(P). Thisprocedure of including each previous block's block digest into thesucceeding block forms a chain of referential connectivity between eachblock of a blockchain so as to establish an immutable record of blockorder within the blockchain. This immutable ordering of blocks within ablockchain inherently establishes an immutable record of the dataincluded in each of the blocks of the particular blockchain, and, hence,of each participating blockchain in the blockchain network 100. Also,the immutability is decoupled from any requirement by an individualblockchain for consensus of the participating nodes to add a block.

A nonce pool 500 may be utilized by each blockchain 200, 300, 400, eachparticipating blockchain 200, 300, 400 having its own nonce pool 500. Acandidate nonce 510 may be drawn from the nonce pool 500. In oneembodiment, the candidate nonce 510 may be generated by an algorithm toproduce a 32-bit integer. The manner of selecting a first candidatenonce 510 may be prescribed by the blockchain protocol of theparticipating blockchain 200, 300, 400, and may be defined by a protocolof the blockchain network 100. The candidate nonce 510 and the blockdigest 30 may be concatenated together 720, 721 to form an input string520. The input string 520 may then be processed 730 by the SHA 600 toproduce 731 a candidate proof-of-work digest (POW digest) 32 based onthe block digest 30. The candidate POW digest 32 may then be compared740 with the target difficulty 40 at 550.

The target difficulty 40 is shown as a hexadecimal value in the presentexample, however, neither the explicit expression 0xFFFF0000 nor thehexadecimal format is required by this disclosure. The target difficulty40 may be expressed in a form that conveys to each blockchain 200, 300,400 of the blockchain network 100 a specific number of consecutive bitshaving an “off” value (or bytes having a “0” value) appearing at eitherthe big or little end of a resulting digest in order to qualify as aPOW. In another embodiment, the target difficulty 40 may be structuredto require a specific number of consecutive bits having an “on” value(or bytes having a “1” value). In another embodiment, the targetdifficulty 40 may require a specific sequence of “off” and “on” bits(“0” and “1” bytes) spanning a designated portion of the candidate POWdigest 32.

If the candidate POW digest 32 does not comply 552 with the targetdifficulty 40, the candidate POW digest 32 and the candidate nonce 510are abandoned 590 and the blockchain returns R₁ to the nonce pool 500. Anew candidate nonce 510 is selected. The manner of selection of the newcandidate nonce 510 may be prescribed by the blockchain protocol of theparticipating blockchain 200, 300, 400, and may be defined by theprotocol of the blockchain network 100, such as, for example withoutlimitation, by always incrementing the nonce value with each iteration,or by always decrementing with each iteration. The new candidate nonce510 may be concatenated to the block digest 30 then processed throughthe SHA 600, then compared 550 for compliance with the target difficulty40. These steps may iterate repetitively, with a new candidate nonce 510for each iteration, until a candidate POW digest 32 is produced whichcomplies with the target difficulty 40.

If the candidate POW digest 32 complies 550 with the target difficulty40, a cursory test 560 is performed to determine if any other POWdigests are required to complete the block 10 POWR 20. Because thecurrent candidate POW digest 32 is a product of the current block 10, atleast one additional POW digest is required. In the current example, twoadditional POW digests are needed. For this reason, the “last digest”test 560 fails 562. The current candidate POW digest 32 may be placed760 in temporary memory 563, and the blockchain 200 returns R₂ to thecurrent candidate nonce 510. The candidate nonce 510 producing thesuccessful candidate POW digest 32 is reused 723 by concatenating thecandidate nonce 510 with the digest 62 (722) to produce an input string530. The input string 530 may be passed 732 to the SHA 600 to produce733 a candidate POW digest 22. The candidate POW digest 22 is thenprocessed 741 to compare to the target difficulty 40. If the currentcandidate POW digest 22 does not comply 550 with the target difficulty40, the current candidate POW digest 22 and candidate nonce 510 areabandoned 552, 590. Furthermore, the previous candidate POW digest 32 isremoved from the temporary memory 563 and abandoned 590. The blockchain200 then returns R₁ to select a new candidate nonce 510.

If the candidate POW digest 22 complies 550 with the target difficulty40, the candidate POW digest 22 may be stored 760 in the temporarymemory 563 along with the previous candidate POW digest 32. Theblockchain continues to iterate through nonce selection R₁, R₂ until acandidate POW digest 32, 22, 24, etc. complying with the targetdifficulty 40 has been generated for each latest block digest 66, 62,64, etc. of the principal blockchain 200 and the participating neighborblockchains 300, 400, etc. Once a target difficulty 40 compliantcandidate POW digest 32, 22, 24, etc. has been generated for each blockdigest 66, 62, 64, etc., each of the candidate POW digests 32, 22, 24,etc. may be placed in the POWR 20 of the block 10. The principalblockchain 200 may also store the successful candidate nonce 510 as theblocknonce 50 in the block 10.

Once the block 10 has been generated, the principal blockchain 200 maypass the block 10 to each of the participating neighbor blockchains 300,400. The block 10 includes the digests 62 and 64, which the blockchain200 received from the last previous block 310 _(P), 410 _(P) of each ofthe respective participating neighbor blockchains 300, 400. In otherwords, an element of the block 10 is the digest 62 from the firstparticipating neighbor blockchain 300 last previous block 310 _(P).Accordingly the digest 62 is received from, then sent back to theparticipating neighbor blockchain 300, which allows the participatingneighbor blockchain 300 to check or otherwise monitor the integrity ofits own stored data and/or transactions. Likewise, the digest 64 wasreceived from, and will be sent back to the second participatingneighbor blockchain 400, allowing the second participating neighborblockchain 400 to verify or otherwise monitor its own integrity ofstored data and/or transactions. The POWR 20 of the block 10 providesassurance to each of the participating neighbor blockchains 300, 400 ofthe validity of the block 10, thereby assuring each of the participatingneighbor blockchains 300, 400 that each is receiving the respectivedigests 62, 64 as the digests 62, 64 were received at the principalblockchain 200. Similarly, the block 10 conveys to each of theparticipating neighbor blockchains 300, 400 the block digest 30. Each ofthe participating neighbor blockchains 300, 400 will return the blockdigest 30 to the principal blockchain 200 with the next subsequent blockfrom each participating neighbor blockchain 300, 400. This permits theprincipal blockchain 200 to authenticate to itself the veracity of theblockchain 200, and hence the transactional records of each block of theblockchain 200. Furthermore, because the principal blockchain 200transmits to each of the participating neighbor blockchains 300, 400 thesuccessful candidate nonce 510, each of the participating neighborblockchains 300, 400 can process each previous block digest 62, 64, 66through SHAs using the disclosed successful candidate nonce 510 toensure that the POWR has been generated according to the blockchainprotocol, and that each block digest 62, 64, 66 is correct. In thismanner, each participating blockchain may have high confidence as to theintegrity of the data—including the order of transactions and digests—ofeach participating blockchain 200, 300, 400, even though eachparticipating blockchain 200, 300, 400 is unaware of the actual data ofevery other participating blockchain 200, 300, 400. This creates animmutable record for each blockchain 200, 300, 400 without a prior needfor trust and without a reliance on consent other than to participate inthe blockchain network 100. In other words, the immutability of the datais decoupled from the consensus of the participating blockchains 200,300, 400.

Furthermore, the ability of each participating blockchain 200, 300, 400to independently verify that the candidate nonce 510 and previous blockdigests (analogous to digests 62, 64, 66 of FIGS. 1, 3) produce targetdifficulty-compliant digests (analogous to 22, 24, 32 of FIG. 3) enableseach of the participating blockchains 200, 300, 400 to recognize ananomaly relative to data of one of the participating blockchains 200,300, 400. In other words, if the participating neighbor blockchain 300performs a verification of the digests (analogous to the digests 62, 64,66) using the candidate nonce 510 reported by principal blockchain 200and any one of the resulting digests from the verification process failsto match the corresponding digest reported by the principal blockchain200, the participating neighbor blockchain 300 may identify the digestanomaly to each participating blockchain 200, 300, 400. This permits thedetection of a data anomaly in a participating blockchain 200, 300, 400of the blockchain network 100 within moments of the event which causedthe anomaly and without disclosure of the actual data involved.Additionally, the participating blockchain 200, 300, 400 identifying theanomaly can also bundle the previously known correct block data with theanomalous data identified and propagate a proof of misbehavior to eachother participating blockchain 200, 300, 400, including that blockchain200, 300, 400 in which the anomaly resides. This cross-reporting of theanomaly, or proof of misbehavior, may enable each participatingblockchain 200, 300, 400 to both insulate itself from possible injectionof bad data, and also provides an audit trail for each computer systemowner/operator to isolate to within a few moments the occurrence of theanomalous data regardless of source. For example, in a worst casescenario, if anomalous data is detected by the participating neighborblockchain 400 in a block from the participating neighbor blockchain 300and the computing system(s) of the entity operating the participatingneighbor blockchain 300 is/are so severely compromised that thecomputing system owner/operator is unable to locate the anomaly byinternal means, the data from any other participating blockchain 200,400 may enable reconstruction of the anomaly event and assist incorrection and mitigation.

By way of example, if a block of the principal blockchain 200 becomesaltered, hence, anomalous, at a neighbor blockchain 300, 400, the digesttransmitted by the neighbor blockchain 300, 400 will not match thedigest calculated by the principal blockchain 200 when the now-anomalousblock is transmitted by the misbehaving neighbor blockchain 300, 400 tothe principal blockchain 200. In this way, the principal blockchain 200(as well as each non-misbehaving neighbor blockchain) may infer thedefect in the transmitted block and simultaneously preserve theimmutability of each non-anomalous block throughout the blockchainnetwork 100.

FIG. 4 is a partial flowchart of an example blockchain 800 at andshortly after startup and having a collection of data 811 pre-dating theblockchain 800 startup according to an embodiment of the presentdisclosure. The blockchain 800 comprises a first block 801 and a seriesof subsequent blocks, of which a first subsequent block 802, a secondsubsequent block 803, a third subsequent block 804, and a futuresubsequent block 805 are shown. The first block 801 comprises a block ID801 _(A), a blockchain version 801 _(B), a blockchain ID 801 _(C), and ablock timestamp 801 _(D). The subsequent blocks 802, 803, 804, and 805may include elements analogous to the block ID 801 _(A), the blockchainversion 801 _(B), the blockchain ID 801 _(C), and the block timestamp801 _(D).

An entity, for example, a company, may have an existing computing system(see 1 in FIG. 1) for transactional record keeping prior totransitioning to or adopting a blockchain similar to the blockchain 800.In some embodiments, the entity may choose to continue to recordtransactions as before implementing the blockchain 800 such that recordkeeping data may continue to be generated in parallel with theblockchain 800. In some embodiments, the entity may choose to adopt theblockchain 800 with future data merklized into the blockchain 800 fromthe date of implementation. The blockchain 800 may participate in ablockchain network similar to the blockchain network 100 of FIG. 2;however, for convenience, the blockchain 800 is illustrated withoutreference to a blockchain network.

A collection of data (pre-existing data) 811, which may comprise anyform of data, for example without limitation, transactional recordkeeping data, may exist prior to the startup of the blockchain 800. Thepre-existing data 811 may be processed through a SHA 820 to produce adigest 821. The digest 821 may be included in the first block 801 of theblockchain 800. In one embodiment, a “first” block may be a pure genesisblock, meaning, the actual initial block of the blockchain 800 maycontain no transactional data digest. In such an embodiment, referencesto the first block 801 apply to the “first” block after the genesisblock.

The blockchain 800 may produce the second block 802 at an intervalfollowing the first block 801 in accordance with parameters of theblockchain 800. The blockchain 800 may merklize 832 any data 812produced after the block 801. In such an implementation, themerklization of the data 812 may produce a merkle root (not shown) whichmay be included in or constitute the digest 842. In conjunction withproduction of the second (first subsequent) block 802, the pre-existingdata 811 may be processed again by the SHA 820 to produce a digest 822.The digest 822 may be compared 852 to the digest 821 of the first block801. If the digest 822 matches the digest 821, no action is taken andthe blockchain continues 854. In other words, block production, and,therefore, the blockchain 800 continues regardless of detection of ananomaly. This is true also when an anomaly is detected in aparticipating neighbor blockchain.

Similarly, in conjunction with production of the second subsequent block803, data following the block 802 may be merklized 833 to produce adigest 843; and a digest 823 of the pre-existing data 811 may beproduced. The digest 823 may be compared 858 to the digest 822 of theprevious block 802. With production of the third subsequent block 803,and each further subsequent block, new data is merklized 833, et seq., anew digest 823, et seq. of the pre-existing data 811 may be generated,with each subsequent digest 823, et seq. compared 858, 864, etc. to theimmediately preceding block's digest 822, 823, et seq. for thepre-existing data 811.

If at generation, for example, of the first subsequent block 802, thedigest 822 does not match the previous digest 821, an alert 856 may begenerated to apprise a computing system owner or operator of themismatch. Such a mismatch may indicate an anomaly in the computingsystem, such as may arise if the pre-existing data 811 has been alteredafter the digest 821 was produced. Such an anomaly need not prevent theblockchain 800 from continuing 854 to operate. Each subsequent block802, 803, 804, etc. may entail a similar comparison 852, 858, 864, etc.of the newest digest 822, 823, 824, etc. of the pre-existing data 811 tothe digest 821, 822, 823, etc. of the pre-existing data 811 for theimmediately preceding block 801, 802, 803, etc. The interval betweeneach block 801, 802, 803, etc. may be determined by the blockchainprotocol of the blockchain 800, and may range from few seconds to anumber of minutes. This interval between block generation comprises thetheoretical maximum period of time between the introduction of ananomaly into the computing system hosting (and/or being monitored by)the blockchain 800 and initial detection of the anomaly. The alert 854,860, 866, etc., may be generated and delivered to a computer owner oroperator within moments of the introduction of the anomaly into thecomputing system.

At the generation of a future block 805 of the blockchain 800, a newdigest 825 of the pre-existing data 811 may be generated. The new digest825 may be compared 870 to the pre-existing data 811 digest of the lastpreceding block. If an anomaly is detected 872, the blockchain 800 maysend an alert 872 and continue in the same manner as before the futureblock 805. If no anomaly is detected, the pre-existing data 811 may bemerklized 880 and included in the digest 845. The digest 845 may beproduced exclusive of the merklized pre-existing data 811 in the eventan anomaly has been detected, based on the data 815 produced since thelast previous block. In other words, the digest 845 may be a digest ofthe new data 815 merklized 835, or it may comprise the merklized 835 newdata 815 and the merklized 880 pre-existing data 811. In anotherembodiment, a series of future blocks, such as the future block 805, mayinclude a digest such as the digest 845 comprising a portion of thepre-existing data 811, such that distinct portions of the pre-existingdata 811 may be included into a series of corresponding distinctivefuture blocks of the blockchain 800. In another embodiment, thepre-existing data 811 may be merklized and included in the first block801, with subsequent data 812, 813, 814, etc. merklized and included inthe corresponding subsequent blocks 802, 803, 804, etc.

FIG. 5 is a diagram of a multiplex network 900 including a blockchainnetwork 960, according to an embodiment of the present disclosure. Themultiplex network 900 may include, in addition to the blockchain network960, one or more local networks and/or non-local networks (not shown).The multiplex network 900 comprises at least a first entity 910 and asecond entity 950. Each entity 910, 950 of the multiplex network 900 maybe organized as one or more divisions. For example, the first entity 910is depicted having at least a first division 920, a second division 930,and a third division 940. Each division 920, 930, 940 of the firstentity 910, and the second entity 950 may each interface with one ormore computer user(s) 922, 932, 942, 952. Each computer user 922, 932,942, 952 may interact with a computing system 924, 934, 944, 954 of therespective division 920, 930, 940 and entity 910, 950. Each division920, 930, 940 may be logically and/or physically separated 912, 914 fromeach other division 920, 930, 940. The first entity 910 may be logicallyand physically separated 918 from the second entity 950.

Each computing system 924, 934, 944, 954 may comprise hardware,software, and firmware (not shown) which, in addition to any otherfunction served, may be capable of creating a variety of logs. Forexample, an accounting software, in addition to recording human readabletransactions, may also generate a log to record when the software wasinstalled, when it was updated, each time it is started (“opened” or“launched”) and closed, user login information, user-audit data,transaction-audit data, etc. Another example may be found in a systemlog generated by the operating system of the computing system 924, 934,944, 954. For purposes of this disclosure, and in particular withreference to FIG. 5, transactional record keeping includes log datagenerated by components of each computing system 924, 934, 944, 954.

The computer user 922 of the first division 920 may interact with thecomputing system 924 of the first division 920 to perform transactionalrecord keeping for the first division 920 of the first entity 910 in theform of a data store 926. The store 926 may comprise any of a genericspreadsheet, a dedicated accounting software platform, a customdatabase, system log, etc. In the example of FIG. 5, the first division920 of the first entity 910 may engage in transactional record keepingoutside a blockchain.

The computer user 932 of the second division 930 may interact with thecomputing system 934 of the second division 934 to perform transactionalrecord keeping for the second division 930 of the first entity 910. Thetransactional record keeping (including log data generated by variouscomponents of the computing system 934 itself) of the second division930 may comprise a data store 936 analogous to the data store 926 of thefirst division 910, and may also comprise a blockchain 938. In oneembodiment, transactional record keeping may take place in parallel inboth the data store 936 and the blockchain 938. In one embodiment, thecomputer user 932 may make transactional record keeping entries into thedata store 936 and the data store 936 may further communicate 937 thetransactional record keeping entries to the blockchain 938. Thetransactional records comprising log data of various components of thecomputing system 934 may be entered (or otherwise stored) directly intothe blockchain 938 by the computing system 934.

The computer user 942 of the third division 940 may interact with thecomputing system 944 of the third division 940 to perform transactionalrecord keeping for the third division 940 of the first entity 910. Thistransactional record keeping may be in the form of a blockchain 948. Thecomputer user 952 of the second entity 950 may interact with thecomputing system 954 of the second entity 950 to perform transactionalrecord keeping for the second entity 950. This transactional recordkeeping may also be in the form of a blockchain 958.

The blockchain network 960 of FIG. 5 comprises at least the blockchains938, 948, 958. For the present example, the blockchain 948 of the thirddivision 940 is also a principal blockchain 962 of the blockchainnetwork 960. The blockchain 938 of the second division 930 is also aninternal participating neighbor blockchain 964 of the blockchain network960. The blockchain 958 of the second entity 950 is also an externalparticipating neighbor blockchain 966 of the blockchain network 960. Theterms “internal” and “external” are relative to the first entity 910because both the principal blockchain 962 and the internal participatingneighbor blockchain 964 are internal to the first entity 910 while theexternal participating neighbor blockchain 966 is external to the firstentity 910.

The principal blockchain 962 and the internal participating neighborblockchain 964 may communicate 968 to exchange block information for thepurpose of cross-merklization. The communication 968 between theprincipal blockchain 962 and the internal participating neighborblockchain 964 may occur in an environment of a private network havingappropriate transmission security protocols. The principal blockchain962 and the external participating neighbor blockchain 966 maycommunicate 970 to exchange block information for the purpose ofcross-merklization. The communication 970 between the principalblockchain 962 and the external participating neighbor blockchain mayoccur in an environment of a public network having appropriatetransmission security protocols.

In one embodiment, the transactional record keeping entries of the datastore 926 of the first division 920 of the first entity 910 may becommunicated 927 to, for example, the blockchain 948 of the thirddivision 940 of the first entity 910. Communication 927 of thetransactional record keeping from the data store 927 of the firstdivision 920 to the blockchain 948 of the third division 940 may affordthe same or nearly same degree of timely anomaly detection for the datastore 926 of the first division 920 as for the blockchain 948 of thethird division 940. The cross-merklization in the blockchain network 960may serve to provide immutable record keeping and timely anomalydetection as described in the present disclosure for each participatingblockchain 962 (948), 964 (938), 966 (958), and provide the same ornearly same degree of immutability and protection for the transactionalrecord keeping of the data store 926.

EXAMPLE EMBODIMENTS

The following are some example embodiments within the scope of thedisclosure. In order to avoid complexity in providing the disclosure,not all of the examples listed below are separately and explicitlydisclosed as having been contemplated herein as combinable with all ofthe others of the examples listed below and other embodiments disclosedhereinabove. Unless one of ordinary skill in the art would understandthat these examples listed below (and the above disclosed embodiments)are not combinable, it is contemplated within the scope of thedisclosure that such examples and embodiments are combinable.

Example 1

A system to detect an anomaly in a monitored computing system, thesystem comprising: a principal computing system implementing a principalblockchain to store record data in a principal series of blocks that arechronologically linked, each block of the principal series of blocksincluding a cryptographic hash of a previous block, a nonce for thecryptographic hash, a target difficulty for the cryptographic hash, atimestamp, and a portion of the record data, wherein the record datastored by the principal blockchain includes data of the monitoredcomputing system; a first neighbor computing system in communicationwith the principal computing system and implementing a firstparticipating neighbor blockchain comprising a series of blocks that arechronologically linked, each block of the series of blocks including acryptographic hash of a previous block, a nonce for the cryptographichash, a timestamp, and a portion of the record data, wherein theprincipal blockchain is to transmit to the first neighbor computingsystem the cryptographic hash, and the nonce for the cryptographic hashof a most recent principal block of the principal series of blocks,wherein the first participating neighbor blockchain is to receive thecryptographic hash and the nonce for the cryptographic hash of the mostrecent principal block and includes the cryptographic hash in a nextblock of the series of blocks, and wherein the first neighbor computingsystem detects an anomaly in the monitored computing system bydetermining whether a subsequent received cryptographic hash of asubsequent block of the principal blockchain is anomalous.

Example 2

The system of example 1, wherein the cryptographic hash comprises abinary hash tree, the final hash results from concatenation with a nonceto form an input string for a one-way cryptographic function, the outputof which complies with a target difficulty that comprises a rulespecifying a compliant cryptographic hash.

Example 3

The system of example 2, wherein the rule indicates a particularcollection of one or more binary values in specified positions of thecompliant cryptographic hash.

Example 4

The system of example 1, wherein the first participating neighborblockchain transmits to the principal computing system the cryptographichash and the nonce of a most recent block of the series of blocks, andwherein the principal blockchain receives the cryptographic hash and thenonce of the most recent block and includes it in a next principal blockof the principal series of blocks.

Example 5

The system of example 4, further comprising: a second neighbor computingsystem implementing a second participating neighbor blockchaincomprising a second series of blocks that are chronologically linked,each block of the second series of blocks including a cryptographic hashof a previous block, a nonce for the cryptographic hash, a timestamp,and a portion of the record data, wherein the principal blockchaintransmits to the second neighbor computing system the cryptographic hashand the nonce of a most recent principal block of the principal seriesof blocks, wherein the first participating neighbor blockchain transmitsto the second neighbor computing system the cryptographic hash the noncefor the cryptographic hash of a most recent block of the series ofblocks, and wherein the second participating neighbor blockchainreceives the cryptographic hash and the nonce for the cryptographic hashof the most recent principal block and includes the cryptographic hashin a next block of the second series of blocks and receives thecryptographic hash of the most recent block and includes thecryptographic hash in the next block of the second series of blocks.

Example 6

The system of example 1, wherein the detected anomaly is reported by thefirst neighbor computing system to the principal computing system torecord occurrence of the anomaly.

Example 7

The system of example 1, wherein, upon the first neighbor computingsystem detecting the anomaly, the first participating neighborblockchain and/or first neighbor computing system returns to theprincipal computing system a previous non-anomalous block received fromthe principal computing system.

Example 8

The system of example 1, wherein an anomaly comprises an incorrectcryptographic hash and/or incorrect cryptographic hash/noncecombination.

Example 9

The system of example 8, wherein the principal computing system, thefirst neighbor computing system, and a second neighbor computing systemeach, independently, verifies whether a shared cryptographic hash and/orcryptographic hash/nonce combination of each other computing systemis/are correct or anomalous.

Example 10

The system of example 1, wherein the principal computing system is themonitored computing system.

Example 11

The system of example 1, wherein the principal computing system isdistinct from the monitored computing system.

Example 12

The system of example 1, wherein the data of the monitored computingsystem comprises log data from logs maintained by the monitoredcomputing system.

Example 13

The system of example 1, wherein the data of the monitored computingsystem comprises data stored by the monitored computing system.

Example 14

The system of example 1, wherein each computing system of the system,including the principal computing system and the first neighborcomputing system, is a monitored computing system.

Example 15

An anomaly detection system to detect an anomaly in monitored data, thesystem comprising: a computing system implementing a participatingblockchain, the computing system comprising: a communication interfaceto communicate with a principal computing system over a communicationnetwork, the principal computing system implementing a principalblockchain to store monitored data of a monitored computing system; amemory to store record data in a series of blocks of the participatingblockchain, the series of blocks chronologically linked, each block ofthe series of blocks including a digest (e.g., a cryptographic hash) ofa previous block, a nonce for the digest, a target difficulty for thedigest, a timestamp, and a portion of the record data; one or moreprocessors in electronic communication with the communication interfaceand the memory, the one or more processors to: implement a protocol ofthe participating blockchain, including adding blocks to theparticipating series of blocks; cross-merklize the participatingblockchain with the principle blockchain by: receiving from theprincipal computing system, over the communication network via thecommunication interface, a digest and a nonce of a most recent block ofthe principal blockchain; and producing a next block of the series ofblocks of the participating blockchain to include the digest of the mostrecent block of the principal blockchain; and detect an anomaly in themonitored data by determining whether a subsequent digest of asubsequent block of the principal blockchain is anomalous.

Example 16

The system of example 15, wherein the principal computing system is themonitored computing system.

Example 17

The system of example 15, wherein the one or more processors are furtherto cross-merklize the participating blockchain with the principleblockchain by transmitting to the principal computing system, over thecommunication network via the communication interface, the digest andthe nonce for the digest of a most recent block of the series of blocks.

Example 18

The system of example 15, the communication interface further tocommunicate with one or more nodes also implementing the participatingblockchain.

Example 19

The system of example 15, wherein detecting an anomaly in the monitoreddata comprises detecting one or more of an incorrect digest and anincorrect digest and nonce combination.

Example 20

An anomaly detection system to detect an anomaly in monitored data, thesystem comprising: a principal computing system implementing a principalblockchain, the principal computing system comprising: a communicationinterface to communicate with one or more neighbor computing systemsover a communication network; a memory to store record data in aprincipal series of blocks of the principal blockchain, the principalseries of blocks chronologically linked, each block of the principalseries of blocks including a digest (cryptographic hash) of a previousblock, a nonce for the digest, a target difficulty for the digest, atimestamp, and a portion of the record data, wherein the record datastored by the principal blockchain includes monitored data; one or moreprocessors in electronic communication with the communication interfaceand the memory, the one or more processors to: implement a protocol ofthe principal blockchain, including adding blocks to the principalseries of blocks; cross-merklize the principal blockchain with a firstparticipating blockchain by: receiving from a first neighbor computingsystem implementing the first participating blockchain, over thecommunication network via the communication interface, a digest and anonce of a most recent block of a series of chronologically linkedblocks of the first participating blockchain; and creating a nextprincipal block of the principal series of blocks to include the digestof the most recent block of the first participating blockchain; anddetect an anomaly in the monitored data by determining whether asubsequent digest of a subsequent block of the principal blockchain isanomalous.

Example 21

The system of example 20, the communication interface further tocommunicate with one or more nodes also implementing the principalblockchain.

Example 22

The system of example 20, the one or more processors further tocross-merklize the principal blockchain with a first participatingblockchain implemented on a first neighbor computing system bytransmitting to the first neighbor computing system, over thecommunication network via the communication interface, the digest andthe nonce for the digest of a most recent block of the principal seriesof blocks.

Example 23

The system of example 20, further comprising a first neighbor computingsystem in communication with the principal computing system andimplementing the first participating blockchain, each block of theseries of blocks including the digest of a previous block, a nonce forthe digest, a timestamp, and a portion of the record data.

Example 24

A computer implemented method of detecting an anomaly in monitored data,the method comprising: receiving monitored data; storing the monitoreddata in record data in a new block of a principal series of blocks of aprincipal blockchain implemented on a principal computing system, theprincipal series of blocks chronologically linked, each block of theprincipal series of blocks including a digest of a previous block, anonce for the digest, a timestamp, and a portion of the record data;transmitting (over a communication network via a communicationinterface) the digest and the nonce for the digest of the new block andof subsequent new blocks to a first participating blockchain beingimplemented on a first neighbor computing system; receiving at the firstneighbor computing system the digest and the nonce of the new block andof subsequent new blocks; and detecting an anomaly in the monitored databy determining whether a subsequent digest of a subsequent new block ofthe principal blockchain is anomalous relative to the digest of anearlier block.

Example 25

A computer implemented method of detecting an anomaly in monitored data,the method comprising: receiving monitored data; storing the monitoreddata in record data in a new block of a principal series of blocks of aprincipal blockchain implemented on a principal computing system, theprincipal series of blocks chronologically linked, each block of theprincipal series of blocks including a digest of a previous block, anonce for the digest, a timestamp, and a portion of the record data;transmitting a digest (and a nonce) of the new block to a participatingblockchain being implemented on a neighbor computing system; receivingat the neighbor computing system the digest (and the nonce) of the newblock; storing the received digest (and the received nonce) in theparticipating blockchain; transmitting a subsequent digest (and asubsequent nonce) of a subsequent new block of the principal series ofblocks to the participating blockchain; receiving at the neighborcomputing system the subsequent digest (and the subsequent nonce) of thesubsequent new block; and detecting an anomaly in the monitored data bydetermining whether the subsequent digest of the subsequent new block isanomalous relative to the digest of the new block.

Example 26

The method of example 25, further comprising: transmitting a digest (anda nonce) of a new participating block of the participating blockchain tothe principal blockchain; receiving at the principal computing systemthe digest (and the nonce) of the new participating block; storing thereceived digest (and the nonce) of the new participating block in theprincipal blockchain; detecting an anomaly in monitored data of theparticipating blockchain by determining whether a subsequent digest of asubsequent new participating block is anomalous relative to the digestof the new participating block.

The described features, operations, or characteristics may be arrangedand designed in a wide variety of different configurations and/orcombined in any suitable manner in one or more embodiments. Thus, thedetailed description of the embodiments of the systems and methods isnot intended to limit the scope of the disclosure, as claimed, but ismerely representative of possible embodiments of the disclosure. Inaddition, it will also be readily understood that the order of the stepsor actions of the methods described in connection with the embodimentsdisclosed may be changed as would be apparent to those skilled in theart. Thus, any order in the drawings or Detailed Description is forillustrative purposes only and is not meant to imply a required order,unless specified to require an order.

Embodiments may include various steps, which may be embodied inmachine-executable instructions to be executed by a general-purpose orspecial-purpose computer (or other electronic device). Alternatively,the steps may be performed by hardware components that include specificlogic for performing the steps, or by a combination of hardware,software, and/or firmware.

Embodiments may also be provided as a computer program product includinga computer-readable storage medium having stored instructions thereonthat may be used to program a computer (or other electronic device) toperform processes described herein. The computer-readable storage mediummay include, but is not limited to: hard drives, floppy diskettes,optical disks, CD-ROMs, DVD-ROMs, ROMs, RAMs, EPROMs, EEPROMs, magneticor optical cards, solid-state memory devices, or other types ofmedium/machine-readable medium suitable for storing electronicinstructions.

As used herein, a software module or component may include any type ofcomputer instruction or computer executable code located within a memorydevice and/or computer-readable storage medium. A software module may,for instance, comprise one or more physical or logical blocks ofcomputer instructions, which may be organized as a routine, program,object, component, data structure, etc., that performs one or more tasksor implements particular abstract data types.

In certain embodiments, a particular software module may comprisedisparate instructions stored in different locations of a memory device,which together implement the described functionality of the module.Indeed, a module may comprise a single instruction or many instructions,and may be distributed over several different code segments, amongdifferent programs, and across several memory devices. Some embodimentsmay be practiced in a distributed computing environment where tasks areperformed by a remote processing device linked through a communicationsnetwork. In a distributed computing environment, software modules may belocated in local and/or remote memory storage devices. In addition, databeing tied or rendered together in a database record may be resident inthe same memory device, or across several memory devices, and may belinked together in fields of a record in a database across a network.

The foregoing specification has been described with reference to variousembodiments, including the best mode. However, those skilled in the artappreciate that various modifications and changes can be made withoutdeparting from the scope of the present disclosure and the underlyingprinciples of the invention. Accordingly, this disclosure is to beregarded in an illustrative rather than a restrictive sense, and allsuch modifications are intended to be included within the scope thereof.Likewise, benefits, other advantages, and solutions to problems havebeen described above with regard to various embodiments. However,benefits, advantages, solutions to problems, and any element(s) that maycause any benefit, advantage, or solution to occur or become morepronounced are not to be construed as a critical, required, or essentialfeature or element.

As used herein, the terms “comprises,” “comprising,” or any othervariation thereof, are intended to cover a non-exclusive inclusion, suchthat a process, method, article, or apparatus that comprises a list ofelements does not include only those elements but may include otherelements not expressly listed or inherent to such process, method,article, or apparatus. Also, as used herein, the terms “coupled,”“coupling,” or any other variation thereof, are intended to cover aphysical connection, an electrical connection, a magnetic connection, anoptical connection, a communicative connection, a functional connection,and/or any other connection.

Recitation in the claims of the term “first” with respect to a featureor element does not necessarily imply the existence of a second oradditional such feature or element. Principles of the present disclosuremay be reflected in a computer program product on a tangiblecomputer-readable storage medium having computer-readable program codemeans embodied in the storage medium. Any suitable computer-readablestorage medium may be utilized, including magnetic storage devices (harddisks, floppy disks, and the like), optical storage devices (CD-ROMs,DVDs, Blu-Ray discs, and the like), flash memory, and/or the like. Thesecomputer program instructions may be loaded onto a general purposecomputer, special purpose computer, or other programmable dataprocessing apparatus to produce a machine, such that the instructionsthat execute on the computer or other programmable data processingapparatus create means for implementing the functions specified. Thesecomputer program instructions may also be stored in a computer-readablememory that can direct a computer or other programmable data processingapparatus to function in a particular manner, such that the instructionsstored in the computer-readable memory produce an article of manufactureincluding instruction means which implement the function specified. Thecomputer program instructions may also be loaded onto a computer orother programmable data processing apparatus to cause a series ofoperational steps to be performed on the computer or other programmableapparatus to produce a computer-implemented process such that theinstructions which execute on the computer or other programmableapparatus provide steps for implementing the functions specified.

Principles of the present disclosure may be reflected in a computerprogram implemented as one or more software modules or components. Asused herein, a software module or component (e.g., engine, system,subsystem) may include any type of computer instruction orcomputer-executable code located within a memory device and/orcomputer-readable storage medium. A software module may, for instance,comprise one or more physical or logical blocks of computerinstructions, which may be organized as a routine, a program, an object,a component, a data structure, etc., that perform one or more tasks orimplement particular data types.

In certain embodiments, a particular software module may comprisedisparate instructions stored in different locations of a memory device,which together implement the described functionality of the module.Indeed, a module may comprise a single instruction or many instructions,and may be distributed over several different code segments, amongdifferent programs, and across several memory devices. Some embodimentsmay be practiced in a distributed computing environment where tasks areperformed by a remote processing device linked through a communicationsnetwork. In a distributed computing environment, software modules may belocated in local and/or remote memory storage devices. In addition, databeing tied or rendered together in a database record may be resident inthe same memory device, or across several memory devices, and may belinked together in fields of a record in a database across a network.

Suitable software to assist in implementing the invention is readilyprovided by those of skill in the pertinent art(s) using the teachingspresented here and programming languages and tools, such as Java,Pascal, C++, C, database languages, APIs, SDKs, assembly, firmware,microcode, and/or other languages and tools.

Embodiments as disclosed herein may be computer-implemented in whole orin part on a digital computer. The digital computer includes a processorperforming the required computations. The computer further includes amemory in electronic communication with the processor to store acomputer operating system. The computer operating systems may include,but are not limited to, MS-DOS, Windows, Linux, Unix, AIX, CLIX, QNX,OS/2, and Apple. Alternatively, it is expected that future embodimentswill be adapted to execute on other future operating systems.

In some cases, well-known features, structures or operations are notshown or described in detail. Furthermore, the described features,structures, or operations may be combined in any suitable manner in oneor more embodiments. It will also be readily understood that thecomponents of the embodiments as generally described and illustrated inthe figures herein could be arranged and designed in a wide variety ofdifferent configurations.

Various operational steps, as well as components for carrying outoperational steps, may be implemented in alternate ways depending uponthe particular application or in consideration of any number of costfunctions associated with the operation of the system, e.g., one or moreof the steps may be deleted, modified, or combined with other steps.

While the principles of this disclosure have been shown in variousembodiments, many modifications of structure, arrangements, proportions,the elements, materials and components, used in practice, which areparticularly adapted for a specific environment and operatingrequirements, may be used without departing from the principles andscope of this disclosure. These and other changes or modifications areintended to be included within the scope of the present disclosure.

The scope of the present invention should, therefore, be determined onlyby the following claims.

1. A system to detect an anomaly in a monitored computing system, the system comprising: a principal computing system implementing a principal blockchain to store record data in a principal series of blocks that are chronologically linked, each block of the principal series of blocks including a cryptographic hash of a previous block, a nonce for the cryptographic hash, a timestamp, and a portion of the record data, wherein the record data stored by the principal blockchain includes data of the monitored computing system; a first neighbor computing system in communication with the principal computing system and implementing a first participating neighbor blockchain comprising a series of blocks that are chronologically linked, each block of the series of blocks including a cryptographic hash of a previous block, a nonce for the cryptographic hash, a timestamp, and a portion of the record data, wherein the principal blockchain is to transmit to the first neighbor computing system the cryptographic hash, and the nonce for the cryptographic hash of a most recent principal block of the principal series of blocks, wherein the first participating neighbor blockchain is to receive the cryptographic hash and the nonce for the cryptographic hash of the most recent principal block and includes the cryptographic hash in a next block of the series of blocks, and wherein the first neighbor computing system detects an anomaly in the monitored computing system by determining whether a subsequent received cryptographic hash of a subsequent block of the principal blockchain is anomalous.
 2. The system of claim 1, wherein the cryptographic hash comprises a binary hash tree, the final hash results from concatenation with a nonce to form an input string for a one-way cryptographic function, the output of which complies with a target difficulty that comprises a rule specifying a compliant cryptographic hash.
 3. The system of claim 2, wherein the rule indicates a particular collection of one or more binary values in specified positions of the compliant cryptographic hash.
 4. The system of claim 1, wherein the first participating neighbor blockchain transmits to the principal computing system the cryptographic hash and the nonce of a most recent block of the series of blocks, and wherein the principal blockchain receives the cryptographic hash and the nonce of the most recent block and includes it in a next principal block of the principal series of blocks.
 5. The system of claim 4, further comprising: a second neighbor computing system implementing a second participating neighbor blockchain comprising a second series of blocks that are chronologically linked, each block of the second series of blocks including a cryptographic hash of a previous block, a nonce for the cryptographic hash, a timestamp, and a portion of the record data, wherein the principal blockchain transmits to the second neighbor computing system the cryptographic hash and the nonce of a most recent principal block of the principal series of blocks, wherein the first participating neighbor blockchain transmits to the second neighbor computing system the cryptographic hash the nonce for the cryptographic hash of a most recent block of the series of blocks, and wherein the second participating neighbor blockchain receives the cryptographic hash and the nonce for the cryptographic hash of the most recent principal block and includes the cryptographic hash in a next block of the second series of blocks and receives the cryptographic hash of the most recent block and includes the cryptographic hash in the next block of the second series of blocks.
 6. The system of claim 1, wherein the detected anomaly is reported by the first neighbor computing system to the principal computing system to record occurrence of the anomaly.
 7. The system of claim 1, wherein, upon the first neighbor computing system detecting the anomaly, the first participating neighbor blockchain and/or first neighbor computing system returns to the principal computing system a previous non-anomalous block received from the principal computing system.
 8. The system of claim 1, wherein the principal computing system is the monitored computing system.
 9. The system of claim 1, wherein the principal computing system is distinct from the monitored computing system.
 10. The system of claim 1, wherein the data of the monitored computing system comprises log data from logs maintained by the monitored computing system.
 11. The system of claim 1, wherein the data of the monitored computing system comprises data stored by the monitored computing system
 12. The system of claim 1, wherein each computing system of the system, including the principal computing system and the first neighbor computing system, is a monitored computing system.
 13. An anomaly detection system to detect an anomaly in monitored data, the system comprising: a computing system implementing a participating blockchain, the computing system comprising: a communication interface to communicate with a principal computing system over a communication network, the principal computing system implementing a principal blockchain to store monitored data of a monitored computing system; a memory to store record data in a series of blocks of the participating blockchain, the series of blocks chronologically linked, each block of the series of blocks including a digest of a previous block, a nonce for the digest, a timestamp, and a portion of the record data; one or more processors in electronic communication with the communication interface and the memory, the one or more processors to: implement a protocol of the participating blockchain; cross-merklize the participating blockchain with the principle blockchain by: receiving from the principal computing system, over the communication network via the communication interface, a digest and a nonce of a most recent block of the principal blockchain; and producing a next block of the series of blocks of the participating blockchain to include the digest of the most recent block of the principal blockchain; and detect an anomaly in the monitored data by determining whether a subsequent digest of a subsequent block of the principal blockchain is anomalous.
 14. The system of claim 13, wherein the principal computing system is the monitored computing system,
 15. The system of claim 13, wherein the one or more processors are further to cross-merklize the participating blockchain with the principle blockchain by transmitting to the principal computing system, over the communication network via the communication interface, the digest and the nonce for the digest of a most recent block of the series of blocks.
 16. The system of claim 13, the communication interface further to communicate with one or more nodes also implementing the participating blockchain.
 17. The system of claim 13, wherein detecting an anomaly in the monitored data comprises detecting one or more of an incorrect digest and an incorrect digest and nonce combination.
 18. A computer implemented method of detecting an anomaly in monitored data, the method comprising: receiving monitored data; storing the monitored data in record data in a new block of a principal series of blocks of a principal blockchain implemented on a principal computing system, the principal series of blocks chronologically linked, each block of the principal series of blocks including a digest of a previous block, a nonce for the digest, a timestamp, and a portion of the record data; transmitting a digest of the new block to a participating blockchain being implemented on a neighbor computing system; receiving at the neighbor computing system the digest of the new block; storing the received digest in the participating blockchain; transmitting a subsequent digest of a subsequent new block of the principal blockchain to the participating blockchain; receiving at the neighbor computing system the subsequent digest of the subsequent new block; and detecting an anomaly in the monitored data by determining whether the subsequent digest of the subsequent new block is anomalous relative to the digest of the new block.
 19. The method of claim 18, further comprising: transmitting a digest of a new block of the participating blockchain to the principal blockchain; receiving at the principal computing system the digest of the new block of the participating blockchain; storing in the principal blockchain the received digest of the new block of the participating blockchain; detecting an anomaly in monitored data of the participating blockchain by determining whether a subsequent digest of a subsequent new block of the participating blockchain is anomalous relative to the digest of the new block of the participating blockchain. 